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BACKGROUND OF THE INVENTION 

1. ) Field of the Invention 

The present invention relates to customizable computer software for use in 
collecting, managing, and analyzing patient medical data. 

2. ) Background of the Invention 

Traditionally, patient medical data has been gathered and stored using paper- 
based systems. With the advancement of computer technology, many hospitals and 
other collectors of patient medical data have sought to automate their processes for 
gathering and managing such data. Thus, handheld computing devices have recently 
been used to gather and manage patient medical data. For instance, software has been 
developed to enable handheld computing devices to be used by paramedics and other 
providers of emergency medical services ("EMS"). This software is typically pre- 
programmed so that the EMS provider is prompted to gather pertinent information, 
such as the patient's name, chief complaint, etc. 

Existing patient medical record software is only customizable to a limited extent. 
Such software typically only allows the EMS provider or administrator to change or edit 
features in a pre-existing data-entry screen. For instance, existing medical record 
software may allow EMS providers to edit the adjectives for severity of pain, or edit a 
list of conditions. 
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1 However, there is a strong need for greater customization. For instance, EMS 

providers may need to create or customize data collection screens on the data- 
gathering software for a future or ongoing study, or for use by a regulatory agency. 
The data-gathering software might also need extensive changes because of a regional 
health situation (such as an outbreak of a particular disease), or because of changes in 
5 medical knowledge. For example, the software might be customized to gather 

information about viagra use in patients with chest pain, since that drug may have 
adverse reactions with nitroglycerin, which is the standard therapy for chest pain. As 
explained below, the present invention provides a software tool (not just a database) 
% that enables administrators to completely customize their data-gathering software. 
;-|0 The present medical data software also lacks a straightforward way to handle 

U multiple modifiers pertaining to a particular body part, such as an ankle that is 
03 "strained/' "swollen/' and "lacerated." The present invention provides a unique 
s "matrix," which allows EMS provider to intuitively gather such information. 

Finally, the current software is not able to integrate two functions: the 
f^5 generation of natural language reports, and the storage of data in a database, which 
allows for complicated data queries and data mining. Instead, existing software 
supports one or the other of these functions, but not both. Thus, there is a need for 
software that stores the patient medical data in a database, but also generates natural 
language reports. 

20 

3.) Brief Summary of the Invention 

The present invention is an integrated medical data software application. The 
invention consists of two parts, "Field Saver" and "Template Manager." FieldSaver is a 
data gathering and management program, which is designed to be used by EMS 
25 providers in the field on handheld computing devices. It has a number of different 
data entry screens that prompt the EMS provider to gather specific information. 
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The EMS provider can navigate backwards and forwards through the screens, 
and certain screens are activated based upon answers to previous questions. For 
instance, if the EMS provider indicates that the subject has chest pain, then FieldSaver 
activates two "chest pain" screens that prompt the EMS provider for more specific 
information, such as a description of the pain (aching, stabbing, severe, etc.), and the 
severity of the pain, on a scale of 1 - 10. FieldSaver also has matrices to gather multiple 
modifiers related to multiple body parts. 

The program is designed to minimize the amount of information that the EMS 
provider must input by typing. Thus, for almost fields, the EMS provider must simply 
select the proper data from a list box, button, or matrix. Each data point — such as the 
subject's weight, or his chief complaint, or the description of a pain felt in his abdomen 
— will be referred to as an item. 

The EMS provider typically selects items by picking from a "list box" containing 
multiple choices. So, for instance, if the subject reports chest pain, the EMS provider can 
select from a list box" specifying whether the pain is described as "aching" or 
"squeezing" and so on. The EMS provider can also manually input data by using the 
character recognizer on the handheld computing device or by typing any item into the 
list box. 

In use, FieldSaver receives information about a particular EMS call through 
remote transmission, and can starting populating screen items based on information 
received from the call, such as the patient's name, address, etc. 

Upon arriving at the scene, the EMS provider could then use FieldSaver to gather 
all necessary data from the call. When the call is complete and all data has been 
gathered, the EMS provider could then generate a natural language report from the 
data. Using a portable printer, the EMS provider could print out the report from the 
emergency vehicle, and provide it to the hospital. The information could also be 
transmitted from the handheld computing device directly to the hospital or other data 



collection point, using any of the remote transmission conduits described below. 

Once the data has been electronically captured in the handheld computing 
device, it could be used in many different ways. For instance, the data can be used as 
part of medical study, for billing purposes, or for analysis by regulatory agencies such 
as the National Highway Safety Transportation Board or local regulatory bodies. 
Indeed, FieldSaver can be specifically programmed to gather categories of information 
that may be needed for such particular purposes. 

Template Manager is a software tool that creates customized medical data entry 
screens for the FieldSaver application. The Template Manager can create new 
FieldSaver screens, and can edit, delete, or duplicate existing screens. In creating new 
screens or "instances," the EMS provider can choose from a number of "templates," 
which provide particular arrangements of labels, buttons, list boxes, and matrices. 

Using Template Manager, an administrator can create and customize virtually all 
aspects of FieldSaver, by (i) adding, removing, or re-ordering items in a list, (ii) 
changing screen titles, labels, and the captions on buttons, (iii) changing the text that is 
displayed in a report when a particular item is selected, (iv) determining the syntax and 
structure of particular items in reports, (v) specifying whether a particular list box 
allows for single select or multiple select, (vi) specifying identifiers for lists and list items, 
(vii) "flagging" items that will be useful for specific purposes, such as advanced life 
support indicators, (viii) for some templates, specifying categories for each list item, so 
that subsets may be displayed, and (ix) for some templates, specifying screens to be 
displayed when a particular item is selected. 

4.) Brief Description of the Drawings 

Fig. 1 shows the system flow of screens for FieldSaver. 

Fig. 2 is a screen shot showing the start screen for FieldSaver. 

Fig. 3 is a screen shot showing the "main" screen for FieldSaver. 



Fig. 4 is a screen shot showing the primary history screen for FieldSaver. 
Fig. 5 is a screen shot showing the physical examination screen for FieldSaver. 
Fig. 6 is a screen shot showing a review screen for FieldSaver. 
Fig. 7 is a screen shot showing the first chest pain screen for FieldSaver. 
Fig. 8 is a screen shot showing the second chest pain screen for FieldSaver. 
Fig. 9 is a screen shot showing a syncope screen for FieldSaver. 
Fig. 10 is a screen shot showing a shortness of breath screen for FieldSaver. 
Fig. 11 is a screen shot showing a treatment screen for FieldSaver. 
Fig. 12 is a screen shot showing the end screen for FieldSaver. 
Fig. 13 is a screen shot showing the utility screen for FieldSaver 
Fig. 14 is a screen shot showing a matrix in FieldSaver. 
Fig. 15 is a screen shot showing the instance selector in Template Manager. 
Figs. 16 - 25 show various template screens that are available to create instances 
in Template Manager. 

5.) Detailed Description 

The present invention has two parts: a data gathering and management 
program, (FieldSaver), and a tool for customizing the data gathering and management 
program (Template Manager). Both of these modules are described in detail below. 

FieldSaver can be used by paramedics and other EMS providers to gather and 
manage patient medical information. It displays a series of screens to prompt the EMS 
provider to enter appropriate patient information. Thus, in addition to its data 
gathering and management function, the program also can be used for training, since it 
guides the EMS provider to gather the information that is needed for proper diagnosis 
and treatment. 

As depicted in Figs. 1 -14, FieldSaver presents EMS providers with a series of 
screens pertaining to particular aspects of the EMS call. The EMS provider can navigate 



back, forth, and between screens. 

The screens have a number of features for data gathering and management. The 
screens typically have a screen title, such as "Start," "Main," or "Chest Pain 1." The 
screens may also have screen labels, that describe particular subparts of a screen. For 
instance, the Physical Exam screen, Fig. 5, has a screen label denoting the "Skin signs" 
portion of that screen. 

Patient data can be entered into screens in a number of ways. A few items, such 
as the patient's name, must be typed in or inputted using a character recognizer, if the 
information has not already been entered electronically via remote transmission. (See. 
Fig 3). But for most all other items, the EMS provider can simply select the appropriate 
data from a list box or matrix. 

For instance, the history screen, Fig. 4, contains a series of buttons on the left side 
of the screen. The first two buttons denote whether the program is currently collecting 
medical related history, or trauma-related history. If the EMS provider selects the 
medical button, then the program displays a series of buttons corresponding to various 
medical categories, such as chest problems, neurological problems, etc. The EMS 
provider can then select the appropriate buttons corresponding to the patient's medical 
history, and the list box to the right will then display a number of possible descriptions 
of the problems. For instance, if the EMS provider selects the 'chest 7 category button, 
then he can choose the particular type of chest problem from the list box, such as 
bradycardia. After the EMS provider has finished entering the data for a particular 
category, that category is highlighted to show it has been chosen. 

Some of the boxes are "single select," meaning that the EMS provider can only 
select one item from the list. For instance, in Fig. 7, the chest pain screen, the EMS 
provider can enter data concerning the severity of the chest pain, ranked on a 1 to 10 
scale. This box is single select, since there can only be one level of severity. However, 
most boxes are multiple select, meaning that the EMS provider can select more than 



one item from the list box. For instance, in Fig. 7, the EMS provider can enter a number 
of items to describe the patient's chest pain, such as "fullness/' pressure/' etc. Many list 
boxes can by augmented in FieldSaver by pressing the exclamation mark within the 
box, as shown in Figs. 7 - 10. By pressing this button, the EMS provider can add new 
choices to the list box. 

FieldSaver also includes a novel data entry means called the matrix. This tool, 
depicted in Fig. 14, allows the EMS provider to quickly select multiple modifiers 
pertaining to a particular body part. For instance, using the matrix, the user can 
designate "bruising," "abrasion," and "tenderness" in the left flank of the abdomen 
simply by pressing buttons corresponding to that body part and those modifiers. 

Many of the screens are linked, so that whenever a EMS provider indicates a 
particular medical condition, another screen is automatically displayed. For instance, if 
the EMS provider indicates that the patient has chest pain, then the EMS provider will 
be prompted to fill out two additional chest pain screens, seeking more particularized 
information. (Figs. 7 & 8). 

The system flow for FieldSaver is depicted on Fig. 1 In this flowsheet, "PE" 
stands for physic exam, "VS" stands for vital signs, "PMHx" stands for patienf s medical 
history, "Dtl" represents detail screens addressing specific medical data, and 'TV" stands 
for intravenous. As described below, the links between screens can be modified using 
Template Manager. 

The first substantive screen in FieldSaver is the start screen, depicted on Fig. 2. 
This screen gathers certain basic data, such as the name of the EMS provider, the run 
number, directions to the call location, and the patient's complaint. Much of this 
information could be populated on the screen when the call is received, by wireless 
transmission from the call center. To accomplish this remote transmission, a number of 
conduits could be used, such as infrared, wireless LAN, or cellular modem IP over 
cellular. At the current time, the preferred method of remote transmission from 
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ambulances is a CDPD (cellular digital packet data) modem to third party CAD 
(Computer Assisted Dispatch) 911 system. 

Using the start screen, the EMS provider can indicate the type of call (Code 2, 
Code 3, ALS transport, Round trip transfer etc.) by clicking on the corresponding 
button, thereby activating a pop-up screen listing the various call types. 

The next screen, depicted on Fig. 3, is the main screen. The EMS provider can 
navigate to this screen by pressing the "main" button on the navigation bar at the 
bottom of the start screen. The main screen acts like the center of a spoke, by linking to 
a number of other screens. This screen gathers basic biographical patient data, such as 
name, date of birth, age, height, weight, etc. It also allows the EMS provider to select 
the type of problem that prompted the call, divided into three categories: pediatric, 
adult, transfer. The main screen also links to a date selector screen, which allows the 
EMS provider to select the patient's date of birth by pressing buttons corresponding to 
the day, month, and year of the patient's birth. 

Once the EMS provider has selected the category of the call (i.e. adult, transfer or 
pediatric), the program then displays the history screen, as depicted in Fig. 4. This 
screen gathers information about the patient's medical history, divided into two 
categories: history of medical problems, and history of traumas. When the "med" 
button is pushed, the program lists a series of sub-categories of potential medical 
problems, such as "chest," "abdomen/uro," etc. When the EMS provider presses the 
button related to the particular sub-category, the list box to the right displays a list of 
potential problems. So, for instance, if the patient has a history of bradycardia, the EMS 
provider would select "med," then "chest" then "bradycardia." 

After the EMS provider has entered patient medical information, a review screen 
can be displayed, reflecting the information gathered thus far in a natural language 
sentence, such as "Chest pain described as fullness, pressure, and tightness and rated as 
8/10." Fig. 6. 
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1 Next, the EMS provider can navigate to a physical examination screen, as 

depicted in Fig. 5. This screen allows the EMS provider to store data gathered during 
physical examination of the patient. As depicted in Fig. 5, the program allows the EMS 
provider to check whether various parts (head, neck, and chest, etc.) are normal or 
abnormal. The screen also allows the EMS provider to note the patient's skin and 
5 vascular signs. 

If the EMS provider has indicated abnormality in a certain body region, a 
separate screen for that body part may be displayed. For instance, if the EMS provider 
indicates problems with the abdomen, a screen specific to that region will be displayed. 
H The screen may use a matrix to correspond body parts to modifiers, such as is displayed 
%q in Fig. 14. As shown in that screen shot, the matrix will allow the EMS provider to 
Jjf indicate multiple conditions of specific body parts by pressing a few buttons. So, to 
s l indicate bruising and abrasions in the right lower quadrant of the abdomen, the EMS 
Cg provider would simply click the "RLQ," "bruising/' and "abrasion" buttons. After 
O finishing the screen, the EMS provider can navigate back to the physical examination 
y|5 screen. 

!L: After the physical examination screen, the treatment screen can be displayed. 

H (Fig. 11). This screen allows the EMS provider to record the time of treatment, and who 
provided it. This screen also links to other screens that capture the patient's vital signs, 
any procedures performed (airway clearing, splinting, spine care, etc.), any intravenous 
20 fluids provided, and any drugs provided. It also links to a screen that allows the EMS 
provider to provide a narrative of the care provided and related details. 

The program also provides an end screen, Fig. 12, that is used to record data 
pertinent to the conclusion of that call, addresses, data concerning billing information, 
and an indication whether other forms should be completed. For instance, if the call 
25 involved hazardous materials, the EMS providers could indicate that a "Haz. Mat." 
form must be filled out. 
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From the end screen, the EMS provider can review all the information entered, 
by pressing the review button. This review, which is depicted in Fig. 5, is a natural 
language collection of all the information collected, organized into sentences. The 
review can also be printed out in a fuller format. When viewed on the screen, many 
terms are abbreviated, but the hard copy version will typically be displayed without 
abbreviations. The report can also be beamed to the hospital or data center, using a 
remote transmission conduit as described above. 

In addition to supporting natural language reports, FieldSaver also stores the 
patient information in a database, so that administrators and researchers can perform 
complicated data queries, and can use the information for data mining. 

There is also a utility screen, Fig 13, which allows the EMS provider to perform 
various utility functions. This screen allows the EMS provider to review all calls for that 
day, to delete all data for a particular call, and to add a new call. This screen displays 
each call stored on the handheld computing device by call number (entered in the start 
screen) and date. It also indicates which EMS provider was responsible for which call. 

FieldSaver was coded with Embedded Visual Basic and Visual Basic. In its 
preferred embodiment, it runs in the Windows CE operating system, on any handheld 
computing device classified as a "Pocket PC/' with a screen of 320 x 240 pixels. 

The second part of the present invention is a software tool, called Template 
Manager, that can create fully customized versions of FieldSaver. While FieldSaver is 
designed for use on a handheld computing device by paramedics and other EMS 
personnel, Template Manager will typically be used on a personal computer by an end 
user content expert, who will customize FieldSaver for a particular group of users. Like 
FieldSaver, Template Manager is coded using Visual Basic, and is compatible with the 
Windows operating system. 

Template Manager presents the user with two different types of screens. The 
first, labeled instance selector, allows the user to select whether to create a new screen 
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or "instance/ 7 or to edit, rename, duplicate, or delete an existing instance. See Fig. 15. 
The term 'instance' is used to denote the fact that each such screen is derived from one 
of the templates provided by template manager. Using the instance selector, the user 
can also provide a name for a new instance, and can choose which one of the various 
templates should be used to create the new instance. There are currently ten such 
templates, each of which contains a different layout of buttons, list boxes, labels, and in 
some cases, matrices. See Figs. 16 - 25. The user can select whichever template seems 
most appropriate given the nature of the new instance. 

The next screen allows the user to customize all aspects of the instance. The user 
can specify the title of the instance, and can decide how the screen should be designated 
on the tab button on the bottom of FieldSaver, using the "tab name" button. See e.g. 
Fig. 17. The user can specify where the screen fits within the overall scheme of 
FieldSaver, by using the "category" button to specify the general category (such as 
adult, pediatric, or transfer), and can use the "minor" button to identify the sub- 
category. 

The user can also completely customize the the list boxes. By pressing the 
"label" button, the user can specify the desired name for the label. See e.g. Fig. 17. The 
user can also customize the captions (labeled with placeholders such as cap 1, cap 2, 
etc.), by highlighting the caption to customized, then typing in the desired text in the 
provided input box. See e.g. Fig. 16. The user can decide whether the text on a caption 
should look the same on the screen and on a print out. (Users may use decide to use 
abbreviations on the screen, but not in the print out). 

The items in the list box can also be customized by pressing on the appropriate 
caption button, then pressing the button for "add item," and then typing in the 
description of the desired item in the input box. As can be seen on Fig. 16, two input 
boxes can be provided for describing list items, one controlling how the item will 
appear when displayed on the handheld computing device (often abbreviated), the 
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other controlling how the item will appear when printed out. Users can also flag 
particular items as relevant for particular purposes, such as "ALS" (advanced life 
support), or code red. By flagging these items, the report can display the significance of 
particular items and flag them for easy data mining later, or add them to a specific list. 
For example, if an item is flagged diagnosis T>X' then it can be listed in the diagnosis list 
for the end user to pick as a final diagnosis instead of having to go and search for it 
from a list. Particular items can also be designated as relevant to data that must be 
gathered for the National Highway Transportation Safety Board (NHTSA), or for any 
local regulatory body. For instance, the NHTSA keeps track of how many traffic 
accidents victims are wearing seat belts (restraints). This data is collected in FieldSaver 
when it is chosen from a list on the MVC (motor vehicle collision) screen. The data will 
print with the report, and then Template Manager will be able to directly field map this 
information into the appropriate field with the appropriate value in a NHTSA report. 

Using Template Manager, a content expert can add new data points or items. 
Each such item, whether new or preexisting, is automatically given a unique numerical 
identifier by Template Manager. This unique identifier is very helpful for data mining 
purposes, since it allows for complicated data queries. 

Template Manager also allows the content expert to control the navigation 
between and among screens. So, for instance, after adding a new item relating to snake 
bites by a particular species, the content expert can designate that anytime the user 
selects that item, a new screen will be displayed, seeking more particularized 
information. 

The program also allows the user to designate that a listing is "single select," 
meaning that the FieldSaver user can only select one item from the list, or "multiple 
select," meaning that the user can select more than one item from the list. For instance, 
in describing the severity of chest pain on a scale of one to ten, only one numerical 
value can be chosen. See Fig. 7. 
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Additionally, Template Manager allows the content expert to control the syntax 
and structure of reports, using the "List" portion of the Template Manager screen. See 
e.g. Fig 17. This feature allows the content expert to decide whether to use "and" or 
another separator between items, and whether to end with a period after the last item, 
or to join the selected list with other data using a specific conjunction. 

Template Manager also allows users to set up matrices, as shown in Fig. 14. By 
creating a new matrix, the content expert can correlate any body part with any set of 
modifiers. 

For some templates, Template Manager allows the user to specify sub-lists under 
particular list items, so that after choosing a list item, a FieldSaver user can input more 
specific information. See Fig. 22. 

The output of Template Manager is a file, sys.data, that is loaded onto each 
handheld computing device that is running FieldSaver, to create customized versions of 
FieldSaver. 

The present invention can be written as two separate computer programs, or as 
two modules within a single system. For purposes of this patent, the term "computer 
module" will include both a stand-alone program, and a discrete module within a 
system. In its preferred embodiment, the present invention is considered an integrated 
system with two modules. 

One skilled in the art will appreciate that the present invention can be practiced 
by other than the described embodiments, which are presented for purposes of 
illustration and not limitation. In particular, although the present invention was 
designed for use with emergency medical services, it could easily be adapted for use in 
other medical and 
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